Website Loading Process - Interview Guide

The Big Picture Question: "What happens when you type a URL?"

This is THE classic interview question! Here's how to structure your answer:

Two Main Phases:

1. Network Phase: Getting the data (DNS → TCP → HTTP)
2. Browser Phase: Rendering the page (Parse → Render → Layout → Paint)

Key Challenges to Mention:

• Latency: Network delays (especially mobile)
• Single-threaded browsers: Main thread blocking affects user experience

Interview Tip: Start with the big picture, then dive into details based on interviewer interest!

Phase 1: Network Operations ("Getting the Data")

Step 1: DNS Lookup

What happens: Browser converts google.com → IP address

Cache Check Order (mention this!):

1. Browser cache
2. OS cache
3. Router cache
4. ISP cache

Interview Answer: "First, the browser checks multiple cache levels for the IP address. If not found, it performs a DNS lookup, which can be slow on mobile networks."

Step 2: TCP Connection (3-Way Handshake)

Client → Server: SYN ("Can I connect?")
Server → Client: SYN-ACK ("Yes, acknowledged")
Client → Server: ACK ("Great, let's talk")

Cost: 3 round trips before any data transfer

Interview Answer: "The browser establishes a TCP connection using a 3-way handshake - SYN, SYN-ACK, ACK. This requires 3 round trips before any actual data can be transferred, which is why connection reuse and keep-alive headers are important for performance."

Step 3: TLS Handshake (HTTPS)

What it does: Establishes secure encryption Cost: 5 additional round trips Total: 8 round trips before actual content!

Interview Gold: "HTTPS requires 8 round trips total - 3 for TCP, 5 for TLS - which is why connection reuse and HTTP/2 are so important."

Interview Answer: "For HTTPS sites, the browser performs a TLS handshake to establish encryption. This adds 5 more round trips on top of the TCP handshake, totaling 8 round trips before any content is transferred. This is why HTTPS can feel slower on first visits, but connection reuse and HTTP/2 help mitigate this overhead."

Step 4: HTTP Request/Response

• Browser sends GET request
• Server responds with HTML
• TTFB (Time to First Byte): Key metric to mention!

Interview Answer: "Once the connection is established, the browser sends an HTTP GET request for the resource. The server processes this request and responds with the HTML content. TTFB (Time to First Byte) measures how long this takes and is a key performance indicator for server response time."

Phase 2: Browser Processing ("Building the Page")

Step 5: HTML Parsing → DOM

What happens: HTML text becomes a tree structure (DOM)

Key Point: Browser has a preload scanner that finds resources early!

Interview Answer: "The browser parses HTML into a DOM tree while the preload scanner identifies critical resources like CSS and JavaScript to fetch in parallel."

Step 6: CSS Processing → CSSOM

What happens: CSS becomes style rules (CSSOM) Important: CSS blocks rendering! (render-blocking resource)

Interview Answer: "The browser parses CSS files and inline styles to create the CSSOM (CSS Object Model). This is a render-blocking resource, meaning the browser won't render the page until all CSS is processed. This is why optimizing CSS delivery and inlining critical CSS is important for performance."

Step 7: JavaScript Execution

Default behavior: Blocks HTML parsing Solutions to mention:

<script async src="script.js"></script>
<!-- Non-blocking -->
<script defer src="script.js"></script>
<!-- Wait for DOM -->

Interview Tip: "I use async for independent scripts and defer for scripts that need the DOM."

Interview Answer: "By default, JavaScript blocks HTML parsing when encountered. The browser must download, parse, and execute the script before continuing. To optimize this, I use 'async' for independent scripts that can run immediately, and 'defer' for scripts that need the complete DOM, as it waits until parsing is finished."

📖 Deep Dive: For comprehensive coverage of JavaScript execution, frameworks like React, performance optimization, and interview questions, see JavaScript Execution Guide

Step 8: Render Tree Creation

Formula: DOM + CSSOM = Render Tree What it excludes: Hidden elements (display: none)

Interview Answer: "The render tree combines DOM structure with CSSOM styling, excluding invisible elements to optimize rendering."

Phase 3: Browser Rendering ("Drawing the Page")

Step 9: Layout (Reflow)

What it does: Calculates exact positions and sizes Triggers: DOM changes, window resize, CSS changes Performance tip: Batch DOM changes to avoid multiple reflows

Interview Answer: "Layout, also called reflow, is when the browser calculates the exact position and size of each element in the render tree. This is triggered by DOM changes, window resizing, or CSS modifications. It's computationally expensive, so I batch DOM changes and avoid layout-triggering properties in animations to optimize performance."

Step 10: Paint & Composite

Paint: Fill in the pixels Composite: Layer everything together (GPU accelerated!)

Interview Answer: "Paint is where the browser fills in the actual pixels for each element, while compositing combines all the layers together. Modern browsers use GPU acceleration for compositing, which is why CSS transforms and opacity changes are much faster than properties that trigger layout or paint. I optimize animations by using transform and opacity properties that only affect the composite layer."

The Critical Rendering Path

Complete sequence: HTML → DOM → CSSOM → Render Tree → Layout → Paint

Interview Gold: "Understanding the critical rendering path helps identify bottlenecks - CSS blocks rendering, JavaScript blocks parsing, and layout changes are expensive."

Interview Answer: "The critical rendering path is the sequence of steps browsers must complete to render a page: HTML parsing creates the DOM, CSS parsing creates the CSSOM, these combine into a render tree, then layout calculates positions, and finally paint draws the pixels. Understanding this helps me optimize performance by identifying bottlenecks - I inline critical CSS to avoid render blocking, use async/defer for JavaScript to prevent parser blocking, and minimize layout-triggering changes during animations."

Key Performance Metrics (Memorize These!)

Core Web Vitals (Google's Standards):

• LCP (Largest Contentful Paint): < 2.5s
• FID (First Input Delay): < 100ms
• CLS (Cumulative Layout Shift): < 0.1

Other Important Metrics:

• TTFB (Time to First Byte): Server response time
• FCP (First Contentful Paint): When content appears
• TTI (Time to Interactive): When page responds to clicks

Interview Tip: "I focus on Core Web Vitals because they directly impact user experience and SEO rankings."

Interview Answer: "I monitor Core Web Vitals as they're Google's official UX metrics: LCP measures loading performance (should be under 2.5s), FID measures interactivity (under 100ms), and CLS measures visual stability (under 0.1). I also track TTFB for server performance, FCP for perceived loading speed, and TTI to ensure the page becomes interactive quickly. These metrics directly impact both user experience and SEO rankings."

Common Optimization Strategies

Network Optimizations:

• ✅ Reduce DNS lookups (fewer domains)
• ✅ Use HTTP/2 multiplexing
• ✅ Enable compression (gzip/brotli)
• ✅ Implement proper caching headers

Rendering Optimizations:

• ✅ Inline critical CSS
• ✅ Use async/defer for JavaScript
• ✅ Minimize layout thrashing
• ✅ Optimize images (WebP, lazy loading)

Interview Answer: "I optimize the critical rendering path by inlining critical CSS, using async JavaScript, and minimizing render-blocking resources."

Interview Questions & Perfect Answers

Q: "What happens when you type a URL and press Enter?"

A: "There are two main phases: network and browser. First, DNS resolves the domain to an IP, then TCP and TLS establish a secure connection - that's 8 round trips total. Once we get the HTML, the browser parses it into a DOM, processes CSS into CSSOM, combines them into a render tree, calculates layout, and finally paints pixels to screen."

Q: "Why is HTTPS slower than HTTP?"

A: "HTTPS requires an additional TLS handshake that adds 5 round trips to establish encryption. However, HTTP/2 and connection reuse minimize this impact in practice."

Q: "What's the critical rendering path?"

A: "It's the sequence browsers follow to render pages: HTML parsing → DOM construction → CSS parsing → CSSOM → Render tree → Layout → Paint. Optimizing this path is key to performance."

Q: "How do you optimize page loading?"

A: "I focus on the critical rendering path: inline critical CSS, use async/defer for JavaScript, optimize images, minimize DNS lookups, and leverage browser caching. I also monitor Core Web Vitals to ensure good user experience."

Q: "What's the difference between async and defer?"

A: "Async downloads and executes immediately without blocking, good for independent scripts. Defer downloads in parallel but waits to execute until DOM is complete, better for scripts that need the DOM."

---

Quick Reference Checklist

Network Phase (8 round trips):

1. DNS lookup (check caches first)
2. TCP handshake (3 round trips)
3. TLS handshake (5 round trips)
4. HTTP request/response

Browser Phase:

1. HTML → DOM
2. CSS → CSSOM
3. DOM + CSSOM → Render Tree
4. Layout (calculate positions)
5. Paint (draw pixels)

Performance Wins:

• Inline critical CSS
• Async/defer JavaScript
• Optimize images
• Minimize DNS lookups
• Use HTTP/2
• Monitor Core Web Vitals